Update GC observability with WeakRefs #129
Conversation
Changing a "must" to "should" here, and referencing the current state of the WeakRefs proposal (multiple implementation support)
index.bs
Outdated
| </div> | ||
| In particular, this means that you should not expose any API that acts as a weak reference, e.g. with a | ||
| property that becomes <code highlight="js">null</code> once garbage collection runs. Such freeing of memory | ||
| should be entirely deterministic. |
There was a problem hiding this comment.
I wonder if we should reword this to say that losing the reference should be deterministic, as we just argued that freeing being implementation-specific is nice. (To be clear, already at fault in the original, so maybe a follow-up.)
There was a problem hiding this comment.
This makes sense. How about I just replace this paragraph for a concrete example, explaining why algorithms like getElementsByTagName are bad, and how you're supposed to do it, and how this ties into GC observability?
| non-interoperable. Worse, according to the usual rules of game theory as applied to browsers, this | ||
| kind of scenario could force other user agents to copy the garbage collection timing of the | ||
| original in order to create interoperability. This would cause current garbage collection | ||
| strategies to ossify, preventing improvement in one of the most dynamic areas of JavaScript | ||
| virtual machine technology. | ||
|
|
||
| In particular, this means that you can't expose any API that acts as a weak reference, e.g. with a | ||
| property that becomes <code highlight="js">null</code> once garbage collection runs. Such freeing of memory must | ||
| be entirely deterministic. |
There was a problem hiding this comment.
I think it's worth keeping this example somehow, since it's a particularly clear and simple example of what it means for an API to depend on GC timing.
| certainly not the same across user agents, which means the resulting code will be | ||
| Although some APIs may expose garbage collection, such as some implementations of | ||
| {{Document/getElementsByTagName}}, and the JavaScript <a | ||
| href="https://github.com/tc39/proposal-weakrefs">WeakRefs proposal</a> (which has multiple |
There was a problem hiding this comment.
It may be worth pointing out that WeakRef is less harmful because it's explicit about its dependency on GC timing, and therefore developers are more likely to be aware of it. Whereas, if an API has something that "randomly" becomes null at some point in the future, authors are likely to be unaware that they're depending on GC timing by assuming it's non-null.
|
Added some wording to get at the great points from @dbaron . |
|
Is this patch blocked on anything in particular? (I'd like to point to this section but it currently still has the outdated content.) |
Changing a "must" to "should" here, and referencing the current state
of the WeakRefs proposal (multiple implementation support). In my mind,
a typical specification review should go just as if the WeakRefs proposal
did not exist; this isn't a justification to expose GC further.